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Purpose 

Describe  our  Approach  to  Extending  DoDAF  to  Unify 
Architecture,  Requirements  and  Requirements  Traceability 
Demonstrate  that  the  DoDAF  can  be  Inline  with  the 
Systems  Engineering  Process 
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Architecture  Framework 
_ Overview _ 


DoDAF  Background 


DoD 

Architecture 
Framework  vl.O 

>  DoDAF  is  Mandated  for  Representing  Architectures  for  the  DoD 

-  Operational,  System,  Technical  Views  (AV,  OV,  SV,  TV) 

-  Addresses  Structure,  Data,  Behavior 

-  Mainly  Diagrams  or  Tables 

>  DoDAF  is  Governed  by  a  Working  Group  with  Representatives 
from  Across  DoD  Services  and  Agencies 

>  Focus  Should  Be  on  the  Underlying  Meta-Data 

-  What  The  Diagrams  Mean,  Not  What  They  Look  Like 

>  Not  Intended  as  a  Systems  Engineering  Tool,  or  as  a  Primary 
Requirements  Vehicle 

-  Tendency  to  be  Descriptive  rather  than  Prescriptive 

-  Doesn’t  Mandate  that  Requirements  be  Specified 

-  Assumes  (but  doesn’t  require)  a  Disciplined  Process  with  Strict 
Consistency  Between  Products 


DoD  Architecture 
Framework  1.0 
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Challenges  for  Our  Project 


>  Desire  to  use  DoDAF  to  Support  Systems  Engineering 

-  Architectures  as  more  than  just  a  Descriptive  Report 

>  Coupled  Architectures  -  Operational,  System,  Software 

>  Linked,  Traceable  Requirements  at  all  Levels 

>  Address  Model  Driven  Architecture  (MDA)  Challenges 

-  Integrated  Architecture  Behavior  Model  (IABM)  to  meet  needs  of 
Single  Integrated  Air  Picture  (SIAP) 

-  Distributed  Nature  of  the  Desired  System 

-  Rapid  Development  Prior  to  Definition  of  the  Full  Set  of 
Requirements  --  Evolutionary/Iterative  Development 

-  Iterative  Development,  Constant  Refinement  of  Requirements 

-  00  Based  Design  Processes  Based  on  UML  notation 
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Architecture  Framework 
_ Overview _ 


Relating  DoDAF  OV  and  SV  Products 

Operational  Views  System  Views 
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Architecture  Framework 
_ Overview _ 


DoDAF  OV  to  SV  Connection  - 


OV-2  / 

Op  / 
Node/ 

Role  •  Activity 

Consumed 


ov-5 


Operational  ^ 
Activity  j 


ode  •  Role 

Produced 


Role 

OV-4 

Op  Node  •  Activity 
Activity  •  Op  Node  • 


SV-4 

System 

Function 


Sys  Node  •  S' 

Consumed 


Matrix  Correlating 
Operational  Activities  to 
System  Functions 
3ys 


Nocte 

•  Function 

Produced 


System/ 

sv-7  / 

Sys  Node  •  Function 
Function  %  Sys  Nod 


>21 


Op  Node 


Operational 

Activity 

t 

Insufficient  Linkage 
Requirements 


Traceability! 


j  Sysiaju 


Node 


Data^ 

System 

Data 

Function 

MITRE 


©  2004  The  MITRE  Corporation.  All  rights  reserved 


A  Systems  Engineering  View 


Systems  Engineering 
Perspective 


>  Requirements  Allocation  and  Traceability  Provide  Rigor  Needed  to 
have  Architecture  Views  Support  System  Engineering 

>  Need  to  Establish 

-  Linkage  Between  Requirements  and  Architecture  Elements  at  Each  Level 

-  Linkage  Between  Requirements  at  Different  Levels 

>  Conventional  Approach  to  DoDAF  vs  Requirements  Aligned  Approach 


Requirements 


DoDAF 

Views 


*1 


System 

Development 


Conventional 

Relationships 


DoDAF 

Views 


System 

Development 


Aligned  Requirements 
Relationships 
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An  Integrated  Architecture  Approach 


►  Architectures  Capture  Requirements  in  Context 

-  Architecture  Views  are  Relevant  to  the  Systems  Engineering  Process  and 
Become  De  Facto  Living  Documents  with  the  Evolutionary  System  Design 

-  Separated  Requirements  may  not  have  the  Meaning  they  have  in  Context, 
or  in  a  Specified  Sequence  (Using  Rules,  Statecharts  or  Sequence 
Representations) 

►  All  Requirements  get  Implemented  through  Something  in  the 
Architecture,  and  there  Should  be  Nothing  in  the  Architecture  that  isn’t 
there  to  help  Satisfy  Requirements 

>  All  Elements  in  an  Architecture  Should  be  Satisfying  one  or  more 
Requirements 

-  Richer  and  Rigorous  Correlation  Between  Requirements  at  Different  Levels 
of  the  Architecture 

-  Can  be  Design-Derived  Requirements 

>  Each  Requirement  Should  be  Allocated  to  at  Least  One  Architecture 
Element  Somewhere 

-  If  all  Requirements  Should  be  Testable,  then  there  must  be  Something  to 
Test 
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Integrated  Architecture 
Approach 


Architecture  -  Requirements  Traceability 

>  Requirements  Apply  to  More  than  Just  Functions 

>  Data,  Interfaces,  and  Behavior  Should  also  have 
Requirements,  and  be  Related  between  OVs  and  SVs 


Operational 

Requirement 


satisfaction 


Flowdown 
To  Design 


flowdown 


Feedback 
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Diagram 

Element 
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Assigning  Requirements  to  an 
Operational  Activity  (Example) 


>  Portion  of  one  of  the  OV-5  Dataflow  Diagrams 

>  Requirements  can  be  Attached  to 

-  Operational  Activities  (boxes) 

-  Information  Exchanges  {data}  (lines) 


Precise  time/position 
reference  data  _ 

Conditioned  SIAP  input 


Orders  and  directives  Planning  products 
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Collect  Aerospace 
Object  State  Date 
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collection 

controls 


Aerospace  object 
state  data 


Integrated  SIAP  track  history; 
Stored  CID  parameters 
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Identification  ROE 
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IFF  controls 


Generate  and  Make 
CID  Determinations; 


CID  res  elution 


Integrated  SIAP  track/non-track  history; 
Stored  CID  parameters - 
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Comprehensive  Approach  for  JSSEO 


>  JSSEO  Project  Characteristics 

-  Based  on  Model  Driven  Architecture  (OMG) 

-  One  Fact,  One  Place 

-  Requirements  Traceability 

-  Auto-Generation  of  Documentation 

>  Agile  Development 

-  Iterative  Requirements  Definition  and  Refinement 

-  Appropriate  for  “Disruptive  Systems”  * 

-  Distributed  System  and  System  Requirements 

>  Support  Implementation  of  Software  to  Heterogeneous  Host 
Systems 

>  Tailoring  of  DoDAF  products 

-  UML  as  Basis  for  System  Views 

*  Clayton  M.  Christensen,  The  Innovator’s  Dilemma 


MITRE 


©  2004  The  MITRE  Corporation.  All  rights  reserved 


Application  to  JSSEO 
MPA  Development 


Role  of  an  Integrated  Architecture  within  JSSEO 


►  Integrated  Architecture  (IA)  Contains 
-Operational  and  System  Architecture 
-Operational  and  System  Requirements 


Extending  DoDAF  to  Address  JSSEO  MDA 


>  Diagram  Adaptation  Primarily  on  the  SV  side. 

>  SV-1,  -2,  -4,  -6,  -11:  Use  UML  Class  and  Object  Diagrams 

-  Variety  of  Uses 

>  Interconnect  Template 

-  The  IABM,  its  Layers,  and  its  Interfaces  to  the  Host  System 

-  Classes  Defined  for  Commonality 

-  Object  Instance  Versions  for  each  Host  System 

>  Capability  Areas 

-  “Virtual”  Classes  Defined  to  hold  Domain-Level  Requirements 

>  Interface  Specification 

-  Associations/Links  can  have  Requirements  Attached,  and  Support 
Message  Definition 
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IA  Operational  Views  &  Requirements 


Application  to  JSSEO 
MPA  Development 


>  Operational  Requirements  (Derived  from  Primary 
Sources)  Associated  with  Diagram  Elements 
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IA  System  Views  &  Requirements 


Application  to  JSSEO 
MPA  Development 


>  System  Requirements  Allocated  to  System  View  Elements 

>  Some  Requirements  derived  from  Architecture  Context 
(Interfaces) 
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IABM  Capabilities  Object  Model  (Example) 


Application  to  JSSEO 
MPA  Development 


>  Links  System  Views  with  IABM  Design 

►  IABM  “Capabilities”  are  Virtual  Objects  used  to  hold  Sets  of 
Related  Domain*  Requirements. 


Track 

Management 

CID 

DDM 


Resource 

Management 
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Value  of  Architecture/Requirements  Process  to  JSSEO 


>  Unified  Repository  of  Integrated  Information 

-  Allows  Automated  Detection  of  Mismatches 

-  Support  for  Automated  Document  Generation 

-  Integrated  Product  Focus  for  Configuration  Control  &  Management 

>  Efficiency:  Engineers  Think,  Tools  Help  Keep  Track 

>  Fewer  Tools  Means  Fewer  Manual  Translations  between  Tools 

-  Every  (manual)  Translation  Provides  an  Opportunity  for  Mis¬ 
translation 

-  Translations  Mean  More  Effort,  More  Complicated  Updating 
Process,  Lower  Probability  of  Continued  Success 

>  Up-To-Date  Design 

-  Architecture,  Requirements,  Design  Updated  Monthly 
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Tool  Adaptation 


Implementing  the  Solution 


>  Architecture  Tool  Adaptation 

-  Architecture  Diagramming  and  Requirements  Management  Tools 
Configured  to  Support  the  JSSEO  Development  Process 

-  Automated  Data  Exchange  Between  Tools  to  Minimize  Data  Entry 
Duplication 

>  Requirements  Management 

-  Flexible  Scheme  for  Identifying  and  Tracing  Requirements 

-  Requirements  Managed  Individually,  not  as  a  Set  within  a  Specification 

>  Metrics,  Reports  and  Status  Monitoring 

-  Oriented  Toward  Determining  Completeness  of  Requirements  Traceability 

-  Account  for  All  Aspects  of  T raceability 

■  Requirement  to  Source 

■  Requirement  to  Requirement 

■  Requirement  to  Architecture  View  Diagram  Elements 

■  Requirement  to  Development  Tool  Domains 
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Adapting  Tools 


►  No  Single  Tool  Meets  All  Needs 

PRIMARY  TOOLS 

►  Popkin  Systems  Architect 

-  DoDAF  Views  (Diagrams) 

-  Requirements  (multiple  levels) 

-  Associates  Requirements  with 
Architecture  Elements 
(Symbols  &  Definitions) 

-  Encyclopedia  of  Architecture 
Data  Stored  in  MS  SQLServer 

►  Telelogic  DOORS 

-  Requirements  Repository 

-  Traceability  Management 

-  Interface  to  Pass  Requirements 
into  Kennedy-Carter  iUML 
Development  Tool 


POPKIN  j  Tele  fog ic 

SOFT  W  A  R  E  •-  -  ^ 


MITRE 


Tool  Adaptation 


Requires  Suite  of  Interoperable  Tools 

SUPPORTING  TOOLS 

>  MS  Excel 

-  CSV  Files  for  Export/Import  of 
Requirements  Between  DOORS 
&  System  Architect 

>  MS  Access 

-  Statistical  Reports  on 
Requirements  Management 

-  SQLServer  Import/Export  of 
Architecture  Data 

>  HTML 

-  Browser  Viewable  Reports  of 
Architecture  Elements  and 
Associated  Requirements 


Microsoft 


WORLD  WIDE  WEB 


c  o  n  sort  i  u  m 


19 


©  2004  The  MITRE  Corporation.  All  rights  reserved 


Popkin  System  Architect 


■ 


Tool  Adaptation 


> 

> 


> 

> 

> 


Configured  for  JSSEO  Development  Process 

-  UML  for  System  Views  to  Align  with  UML  in  MDA 


Modified  USRPROPS.TXT  file 

-  Added  Requirement  Definitions  (Addressables) 
for  Operational,  System,  and  Domain 
Requirements 

-  Extended  Symbol  Definitions  to  Accept 
Associations  of  Requirement  Addressables 

-  Extended  System  Requirement  Definition  to 

Accept  Associations  of  Operational  and  Domain 
Requirement  Addressables  - 

Used  to  Build  DoDAF  OVs  and  SVs 


Diagram 


1..* 


Diagram 

Element 


+destination  element 
rqmt 


alloc 


Imports  Requirements  from  DOORS  Repository 
(via  Excel  Files) 

Assigns  Requirements  to  Diagram  Elements 


+rqmt  1-* 
Requirement 


-  Drag  and  Drop  Requirements  to  Diagram 
Symbols 
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Tool  Adaptation 


Attaching  Requirements  To  A  Symbol 


Tool  Adaptation 


Defining  Requirements  Linkages 


Operational  Requirements 
Traced  to  System  Requirement 
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Requirements  Management 


■ 


Requirements 

Management 


>  Requirements  Database  in  DOORS 

-  Independent  Operational,  System, 
and  Domain  Requirement  Lists 

-  Unique  Identifier  for  Each 
Requirement 

-  Requirement  Attributes  for  Status 

Tracking  ^ 

>  Traceability  to  Source  Documents, 
Between  Requirements  and  to 
Architecture  Elements 

>  Reports  on  “Orphan”  Requirements 
or  Architecture  Elements  Produced 
from  both  SA  and  DOORS 


Requirement 
^>TRL_ID  :  Integer 

£?•  IABM  Technical  Requirement  :  String 
^>TB  Deferred  From  :  Integer 
%TB  Assigned  To  :  Integer 
^■Participation :  Object 
^■Requirement  ID  :  String 
%Domain  :  String 
^Implementation  Status  :  String 
^Requirement  Status  :  String 
^>Notes  :  String 
S^Test  Status  :  String 
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Requirements 

Management 


Requirement  Internal  Meta  Structure  &  States 


Requirement 


Requirements  Class  State  Chart 


Only  Current  Requirements  are  Linked 

-  Linkages  to  Diagram  Element,  Other 
Requirements,  or  Source  Document 

Superseded  or  Cancelled  Requirements 
are  Archived 


Requirements  are  Approved  Prior  to 
Assigning  Linkages 

Requirements,  Once  Created,  Stay  in 
System 
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Requirements  Work  Flow 


Requirements 

Manaaement 


>  Movement  of  Requirements  Between  Tools  Requires 
Adaptation  of  'One  Fact  One  Place’  Program  Goal 

-  Requirement  Definition  in  DOORS 

■  Exported  to  System  Architect 

-  Requirement  Relationships  Defined  in  System  Architect 

■  Exported  for  Detailed  Reporting 

■  Exported  to  DOORS  for  Traceability  Management 
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Requirements 

Management 


Tool  Suite  Interoperability 

_  -  -  '  / 
-  -  "  / 


Microsoft 


Modified 

USRPROPS.TXT 


Encyclopedia 
(SQL  Server) 


Aligned  Requirements 


Architecture  Data 


Requirements 


Requirements 

Repository 


Excel  CSV  File 
of  Requirements 


Telelogic 


Kennedy-Carter 
iUML  Development  Tool 


Traceability 
Management  & 
Reports  (MS  Access) 
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Metrics  and  Reports 


>  Measuring  the  Goodness  of  Traceability 

-  Completeness  of  Architecture  Views 

-  Completeness  of  Requirements  Set 

>  Traceability  Statistical  Reports 

-  Used  to  Assess  Architecture  and  Requirements  Traceability 

-  Requirements  Traced  into  the  Architecture 

-  Architecture  Elements  Aligned  with  a  Requirement 

>  HTML  Reports  from  System  Architect  and  DOORS 

-  Provides  Access  to  Architecture  and  Requirements  Information 
without  Requiring  Expertise  in  Tools 

-  Permits  Wide  Review  Without  need  for  Special  Tools 


Reports  used  to  Improve  Overall  SIAP  Development  Process 


MITRE 
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Requirements 

Management 


Requirements  Traceability  Reports 


>  Reports  Built  in  MS  Access  using 
Data  Extracted  from  System  Architect 
Encyclopedia  (MS  SQL  Server) 

-  Architecture  and  Requirements 
Traceability 

-  Requirements  Accounted  for  in  the 
Architecture 

-  Architecture  Elements  with  Assigned 
Requirement 


E  Microsoft  Access  -  [ORL  Trace  of  SRL  :  Report] 

BIS® 

:  a  File  Edit  View  Tools  Window  Help  Type  a  question  for  help 

-  -  0  x| 

j  ^  |  Q  |Cli|  -|J  1  i  ^  Fit  -  Close  Setup 

fLiL^LiJ 

Operational  Requirements  Traced  to  System  Reqjrements 


Ready 
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HTML  Reports 


Requirements 

Management 


-  Symbols  to  Symbol  Definition  (Includes  Assigned  Requirements) 

-  Requirement  Name  to  Corresponding  Definition 

-  Requirements  to  Requirements 
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■ 


Summary 


Future  Work 


>  Comprehensive  Hyper-linking 

-  VB  Scripts  used  to  create  hyper-linked  Integrated  Architecture 

-  Linkages  with  HTML  from  DOORS  and  iUML  Tools 

-  Complete  Requirements  Trace  From  Source  Documents  to  IABM 
Domain  Classes 

>  Additional  Reporting  &  Analysis  Features 

>  Direct  Database  Exchanges  to  Minimize  need  for  File 
Export/Import  to  Move  Data  between  Tools 
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Summary 


■ 


Summary 


>  Presented  the  Approach  for  Linking  Architecture  and 
Requirements. 

-  Architecture  Views  Serve  to  Place  Requirements  in  Context 

>  Demonstrated  the  Current  State  of  JSSEO  Products,  Metrics, 
Reports 

>  Metadata  Structure,  Configuration  Data  in  the  usrprops.txt  file, 
is  U.S.  Government  Owned,  and  Releasable  (through  JSSEO) 

>  Requirements  Must  Be  Developed  By  All,  Integrated  With 
Architecture 


Requirements,  Design,  or  Behavior  that  is  not  Part  of 
an  Integrated  Architecture  is  not  Defensible 
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